Merged
Conversation
* move cmd.[ch] and usb_cdc.[ch] to armsrc * sorting out #includes * replace byte_t by uint8_t * some reformatting * whitespace fixes * (no functional changes)
* merge cmd.c into usb_cdc.c * move back usb_cdc.[ch] to common/ * declare low level functions usb_read() and usb_write() and more functions as static * use cmd_receive() in bootrom.c and appmain.c * remove unused memory wasting csrTab[100] in usb_cdc.c * replace more byte_t by uint8_t * more whitespace fixes
* use different data types for commands and responses * use variable length responses * maintain client/flasher compatibility with old format (e.g. when using old bootloader) * maintain bootloader compatibility with old format (e.g. when using old or RRG flasher.exe) * fix length of version string in appmain.c
* ensure that CMD_ACK is used exclusively for the very last response of each PM3 operation. All Dbprintf() must be before. * always switch off field before exiting * append null packet for USB transfers % 64 bytes * reformatting and whitespace fixes
* whitespace fixes * sorting out #includes
* added some LED handling in appmain.c (helped with debugging) * finally replaced the infamous device unlink by msleep(1000) * fixed some format strings in comms.c (with -DCOMMS_DEBUG) * made uart_receive() and uart_send() behave as described in header * some formating
Contributor
Author
|
With the latest commit we have uart_posix.c behave like uart_win32.c. and with less blocking. Key checking rate on Kali Linux is now much better but still slightly behind Windows (233 vs 235 key/sec). No idea where the rest is lost... |
Contributor
Author
|
replacing msleep() in WaitForResponseTimeoutW() by some pthread-signalling in GetCommand() brought the Windows implementation back to the 238keys/sec we had seen before and Kali Linux to 237keys/sec. I still have no idea why it is slower on Linux. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This was initiated by @uzlonewolf's idea of "command queuing" which sended new commands to PM3 before the previous had been acknowledged. This didn't work for Windows (see discussion in #901). It turned out that this was in fact another approach to circumvent the timeouts in uart_receive() which tend to delay uart_send(). The same was already achieved by blocking the communication thread on CMD_ACK during flashing.
This PR enables the block on CMD_ACK in general. Plus it allows variable sized responses similar to @doegox's work on RRG repo (but with less code changes).
Ah yes, and this improves the key checking speed from 219keys/sec to 238 keys/sec.